The IP Multimedia Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia services. It constitutes an approach to providing internet based multimedia services, including voice calls and messaging, to various wireless telecommunications networks, such as Global System for Mobile Communications (GSM), wireless LAN, and Universal Mobile Telecommunications System (UMTS), as well as fixed line networks. One of the protocols used in the IMS network is the Session Initiation Protocol (SIP). A terminal used with the IMS network is referred to as SIP terminal.
FIG. 1 shows a basic signalling diagram in an IMS network 10, for initiation of a call, or SIP session from one SIP User Agent (SIP UA (A)) 12 to another SIP UA (SIP UA (B)) 38. For clarity, the signalling diagram shows only the SIP signalling up to the arrival of a SIP Invite message at the destination party's terminal, i.e. SIP UA (B) 38. In addition, the signalling diagram does not reflect the user plane (media transport).
A SIP Invite message 14 is initiated in the SIP UA (A) 12, and sent to a Proxy Call Session Control Function (P-CSCF) 16 of user A. The SIP invite message 14 is forwarded from the P-CSCF 16 to a Serving CSCF (S-CSCF) 18 associated with user A.
An S-CSCF contains an internal database of the subscribers (i.e. users) registered with that S-CSCF. Thus, when the S-CSCF 18 of user A receives the SIP Invite message 14 from the P-CSCF 16 of user A, it uses the P asserted-ID (PAI) header of the SIP Invite message to obtain user A's registration data from the database, i.e. ‘matches’ the Invite message with a registered user.
The SIP Invite message 14 also contains some information identifying the called party, i.e. user B. Such information may include a public user identity of user B, or a telephone number of user B, for example. If the destination party is identified in the SIP Invite message 14 with a Universal Resource Identifier (URI) indicating an IMS user, then the S-CSCF 18 will apply outbound routing as described below. If the destination party is identified with a phone number, then the S-CSCF 18 will communicate with an E.164 Number Mapping node (ENUM) 20 in order to obtain a URI indication of the IMS user. The further action by the S-CSCF 18 is determined by the outcome of an ENUM query message 22 sent from the S-CSCF 18 to the ENUM 20. If the ENUM indicates to the S-CSCF 18, in the ENUM response message 24 to the aforementioned ENUM query 22, that the destination party is a subscriber of the IMS network, then the S-CSCF 18 will apply outbound routing as described below. Otherwise, the S-CSCF 18 takes a breakout to a Circuit-Switched (CS) network (not illustrated).
For outbound routing, the S-CSCF 18 forwards the SIP Invite message 14 to an Interrogating CSCF (I-CSCF) 26 associated with user B. The I-CSCF 26 is a SIP function located at the edge of an administrative domain. Its IP address is published in Domain Name System (DNS), so that remote servers (e.g. S-CSCF 18) can find it, and use it as a forwarding point for SIP messages to this domain.
The I-CSCF 26 communicates with a Home Subscriber Server (HSS) 28 to determine the S-CSCF with which user B is registered. The HSS 28 comprises a database containing the registration information of all users registered with that particular network. Thus, the I-CSCF 26 sends a Diameter Location Information Request (LIR) message 30 to the HSS 28, and receives a Diameter Location Information Answer (LIA) message 32 in reply, identifying the S-CSCF with which user B is registered.
The I-CSCF 26 forwards the SIP Invite message 14 to the S-CSCF 34 of user B. The S-CSCF 34 of user B, similarly to the S-CSCF 18 of user A, comprises a database of all users registered with it. On receipt of the SIP Invite message 14, the S-CSCF 34 looks up the user identified as the called party in the message, and forwards the message 14 to a P-CSCF 36 associated with user B. The P-CSCF 36 then forwards the message to the SIP UA (B) 38, and the path of the SIP Invite message 14 is complete.
Thus, it can be seen that, first, the S-CSCF 18 of user A may not have knowledge about the IMS network that the destination subscriber (user B) belongs to; this is especially true when user B is identified in the SIP Invite message 14 with an enterprise-specific domain name, such as sip:joe.bloggs@abb.se. Second, the S-CSCF 18 of user A has no knowledge of which S-CSCF, in the IMS network of user B, is serving user B.
For the purposes of the first issue, the S-CSCF 18 of user A applies ‘egress routing’. This entails the S-CSCF 18 contacting DNS to obtain the address of an inbound proxy of the IMS network serving user B. This inbound proxy may be an I-CSCF 26 as in the illustrated example, or an Interconnect Border Control Function (IBCF) of the network serving user B. An IBCF is used between different IMS networks. If the inbound proxy is an IBCF, then the IBCF will take care to forward the call to an I-CSCF in the IMS network of user B.
For the purposes of the second issue, the I-CSCF 26 of user B's network will, once the call has arrived at that I-CSCF 26, contact the HSS 28 (of user B) to obtain the address of the S-CSCF currently serving user B.
The call can only then, using the information received by the I-CSCF 26 from the HSS 28, be routed further, from the I-CSCF 26 to the S-CSCF 34 of user B. The S-CSCF 34 may now process the terminating call.
It can be seen, therefore, that a relatively large amount of signalling is required to determine the necessary information for forwarding the call from a first user to a second user. Moreover, this signalling crosses a number of different nodes in the system 10, adding delay to the call process.